When a `:ty` matcher is used in a `macro_rules!` macro, the captured
argument can no longer be used to match a literal in a new
`macro_rules!` invocation. For example, the following code:

```rust
macro_rules! inner {
    (my_val) => {}
}

macro_rules! outer {
    ($val:ty) => {
        inner!($val);
    }
}

outer!(my_val);
```

produces the following error:

```
error: no rules expected the token `my_val`
  --> src/lib.rs:7:16
   |
1  | macro_rules! inner {
   | ------------------ when calling this macro
...
7  |         inner!($val);
   |                ^^^^ no rules expected this token in macro call
...
11 | outer!(my_val);
   | --------------- in this macro invocation
   |
   = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)
```

That is, once `my_val` is captured as a `:ty`, it will not match a `my_val` literal
in the `inner!` invocation.

Due to a bug in rustc, code like this was accepted by the compiler
when a proc-macro attribute was applied to the macro invocation.
This affects `fourier-algorithms` due to the following code:

```rust
#[target_cfg(target = "[x86|x86_64]+avx")]
crate::avx_vector! { $type };
```

The `avx_vector!` macro is expecting either `f32` or `f64`
as an ordinary token. However, the `$type` metavariable uses a
`:ty` matcher, which will prevent it from matching against `f32`
or `f64` (even though the captured type is always `f32` or `f64`).

Due to the `target_cfg` attribute proc-macro, this code was incorrectly
allowed to compile. When the underlying bug in rustc is fixed
in rust-lang/rust#73084, `fourier-algorithms`
will stop compiling.

This commit changes two `:ty` matchers to `:ident` matchers, which can
be used as arguments to a `macro_rules!` macro expecting a plain `f32`
or `f64` token. This will still compile on existing compile versions,
and will allow `fourier-algorithms` to continue to compile once
rust-lang/rust#73084 is merged into rustc.